home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc949 < prev    next >
Text File  |  1995-07-25  |  4KB  |  114 lines
  1.  
  2. Network Working Group                                     Mike Padlipsky
  3. Request for Comments: 949                                          Mitre
  4. Semisupersedes RFC 505                                         July 1985
  5.  
  6.                      FTP UNIQUE-NAMED STORE COMMAND
  7.  
  8.  
  9. STATUS OF THIS MEMO
  10.  
  11.    This RFC proposes an extension to the File Transfer Protocol for the
  12.    ARPA-Internet community, and requests discussion and suggestions for
  13.    improvements.  Distribution of this memo is unlimited.
  14.  
  15. DISCUSSION
  16.  
  17.    There are various contexts in which it would be desirable to have an
  18.    FTP command that had the effect of the present STOR but rather than
  19.    requiring the sender to specify a file name instead caused the
  20.    resultant file to have a unique name relative to the current
  21.    directory.  This would be useful for all sorts of "pool" directories;
  22.    the directories that serve as queues for printer daemons come
  23.    immediately to mind (so do fax and even cardpunch daemons' queues),
  24.    although naturally the sort of printer queue that a local command has
  25.    to manage the interface to isn't what's meant by "pool" in this
  26.    context.
  27.  
  28.    If we accept the need for such an FTP extension, and that it should
  29.    not be done with an "X" command because it needs to be relied on
  30.    "everywhere," the interesting question then becomes how to mechanize
  31.    it.  Probably the most natural way to do it would be either to add a
  32.    "control argument" of -UNM to the syntax of STOR, now that there are
  33.    enough UNIXtm's around so that this good old Multics trick isn't
  34.    alien any more, or even to declare that STOR with no argument should
  35.    cause a directory-unique name to be generated.  However, either of
  36.    these would necessitate "reopening" the STOR command code, which is a
  37.    distasteful sort of exercise.  Since most FTP's presumably do a
  38.    dispatch sort of thing off a list of command names to begin with,
  39.    then, an additional command would seem to be the way to go.
  40.  
  41.    Naming the command calls for a bit of thought.  STore Uniquely Named
  42.    (-> STUN) is silly; UNIQue comes to close to free advertising or even
  43.    trademark infringement (and confuses fingers if you're typing); Store
  44.    Uniquely NaMed (-> SUNM) doesn't avoid free advertising either;
  45.    Uniquely Named STore (-> UNST) might look like a synonym for DELEte,
  46.    though it's not all that bad; SToRe Uniquely named (-> STRU) is
  47.    taken; and so it goes.  The best bet seems to be STOU.
  48.  
  49.    Of somewhat more practical import, there's also the question of
  50.    whether the sender needs to be apprised of what the unique name
  51.    turned out to be.  Intuitively, sometimes this would be the case and
  52.    sometimes it wouldn't.  Making it optional is almost certainly too
  53.  
  54.  
  55. Padlipsky                                                       [Page 1]
  56.  
  57.  
  58.  
  59. RFC 949                                                        July 1985
  60. FTP Unique-Named Store Command
  61.  
  62.  
  63.    much like work, though--even if it does have the subtle virtue of
  64.    finally getting control arguments into FTP.  Therefore, why not just
  65.    include it in a suitable response-code's free text field (unless, of
  66.    course, an avalanche of comments comes in urging it not be done at
  67.    all)?
  68.  
  69.    Note, by the way, that the intent here is emphatically not to
  70.    sidestep whatever access control, authentication, and accounting
  71.    mechanisms Hosts might have in play before the user can do an old
  72.    STOR or a new STOU, but with suitable publicized ID's and passwords
  73.    it could be almost as good as the proposal made in RFC 505.
  74.  
  75. RECOMMENDATION
  76.  
  77.    Add a new command, STOU, to FTP, which behaves like STOR except that
  78.    the resultant file is to be created in the current directory under a
  79.    name unique to that directory.   The 250 Transfer Started response
  80.    should include the name generated (unless the copy of FTP I have is
  81.    so old that 250 isn't the right number any more).
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Padlipsky                                                       [Page 2]
  113.  
  114.